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SERVICE REQUEST COMMON OBJECT 

CROSS REFERENCE TO RELATED APPLICATIONS 

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 

60/457,305 filed March 24. 2003, entitled, "SERVICE REQUEST COMMON 
OBJECT," by Barnes et al., and which is hereby incorporated by reference in its 
entirety. 

TECHNICAL FIELD 

[0002] The present invention is directed to the field of data modeling in the context 

of enterprise resources planning and customer relations management, and more 
specifically to service request management. 
BACKGROUND 

[0003] Many enterprise systems use call centers to interface with customers. Such 

call centers may use call center business processes to process customer requests. 
An example of a customer request is a request for service or "service request". 

[0004] For example, assume that a customer calls to report a loss of service. A loss 

of service is also referred to herein as a network outage. Call center agents face a 
challenge to manage customer service requests and the network outages in the 
shortest amount of time. The call center is referred to as the front-office. 

[0005] Typically, network outages are managed by a network operations center 

(NOC). The network operations center is referred to as the back-office. Further, the 
individuals who act as call center agents are distinct from the individuals in the 
network operations center. The two groups typically do not communicate with each 
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other. In addition, the call center and the network operations center, each use 
different applications. For example, the call center agents use a call center 
application in the call center's computerized system to record customer technical 
problems as service requests. On the other hand, the network operations center 
uses technical applications such as a network management system in the network 
operations' computerized system to detect and fix problems such as network 
outages. 

[0006] Typically, the call center applications are not linked to the network 

management systems. Although the network management system can detect and 
recognize a network outage, such information is usually not communicated to the 
call center agents and the call center applications. Therefore, when a customer 
contacts the call center to report a loss of service, the call center is usually not 
aware of the network outage. In response to a customer's complaint regarding the 
network outage, the call center agent collects the network outage information as a 
ticket and sends the ticket to the appropriate individuals to resolve the ticket. 

[0007] Thus, a mechanism is needed to synchronize the information associated with 

service requests and network outages between the front-office applications, e.g., 
the call center applications, with the back office applications, e.g., the network 
management system applications. 

[0008] Generally, in order for front-office computerized systems to communicate with 

back-office computerized systems or vice versa, the user must manually regenerate 
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data from the back-office computerized systems in forms usable by the front-office 
computerized systems, and vice versa. Such manual regeneration has several 
significant disadvantages, including: (1) it is often expensive; (2) it often requires a 
substantial amount of time to complete; (3) it must be repeated each time data 
changes in either the back-office system or the front-office system; and (4) it is 
prone to errors. 

[0009] In view of the foregoing, an automated approach for synchronizing data used 

by a back-office computerized system with data that is use by a front-office 

computerized system, and vice versa, is needed. 

BRIEF DESCRIPTION OF THE DRAWINGS 
[0010] FIG. 1A is a high level network diagram showing aspects of a computerized 

environment in which the facility operates, according to certain embodiments. 
[0011] FIG. 1B is a block diagram showing some of the components typically 

incorporated in at least some of the computer systems and other devices on which 

the facility executes. 

[0012] FIG. 2 is a high level flow diagram that shows some steps typically performed 

by the facility in order to convert service request information from the one or more 
source formats to the target format. 

[0013] FIG. 3A illustrates some a process flow for fulfilling a service request. 

[0014] FIG. SB illustrates a process flow for an online self-service to obtain service 

requests. 
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[0015] FIG. 4 illustrates an integration business process (IBP) for Synchronizing 

service request information between the source and target systems. 

[0016] FIG. 5 to FIG. 17 are data structure diagrams of the service request common 

object model. 

DETAILED DESCRIPTION 

[0017] When a customer contacts the call center to report a loss of service, the call 

center is usually not aware of the network outage because the call center 
applications are not linked to the network management systems. Although the 
network management system can detect and recognize a network outage,, such 
information is usually not communicated to the call center agents and the call center 
applications. A more proactive method would be to synchronize the service request 
information and network outage information by linking the network management 
system applications to the call center applications. 

[0018] The synchronization operation provides users associated with the call center 

and network operations the same view of customer service requests and network 
outage information across the various computer applications. All changes in the 
customer service requests and the network outage information need to be captured 
and made accessible to all relevant computer applications in the enterprise system. 
The computer applications of the front-office system uses a data model that is 
distinct from the data model used in back-office system's computer applications. 
Thus, a common data storage model is needed so that the various computer 
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applications across the enterprise system can share the service request information 
and network outage information. 

[0019] According to certain embodiments, the front-office applications such as the 

call center applications can be linked to the back-office applications such as the 
network operations applications by using a data model that includes a service 
request common object. 

[0020] If the network management system applications are linked to the call center 

applications using a service request common object, then when a network outage 
occurs, the network management system can communicate with the call center. For 
example, the network management system can request that a service request be 
opened in the call center application. If a customer calls to report the network 
outage, the call center agent would be able to verify the customer's outage and 
report the current activity on the opened service request. 

[0021] Call centers may use certain call center business processes to process 

customer requests. Such call center business processes may enable a call center 
agent to perform the following: 

1) initiate or create a service request in a multi-application integration system 
(MAIS); 

2) capture the details of the service request 

3) verify entitlements; 

4) research and resolve the service request; 
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5) escalate service requests (if necessary); 

6) create customer orders (if necessary); and 

7) close service request. 

[0022] A software facility (hereafter "the facility") for automatically synchronizing 

service request information, is described. In some embodiments, the facility 
converts service request information from a form used by the source system to a 
form used by the target system. In certain embodiments, source systems may be 
front-office systems such as customer call centers. In certain embodiments, target 
systems may be back-office system providing support for network operations. 
However, the network operations center may need to initiate service request 
information, then the network operations center is referred to as the source system 
and the call center becomes the target system. 

[0023] In some embodiments, such as embodiments adapted to converting service 

request information in the first source format, the facility converts service request 
information by converting the service request information that is in the first source 
format into an intermediate format. The intermediate format is then used to convert 
the service request information into the target format. 

[0024] By performing such conversions, embodiments of the facility enable a user of 

a first computerized system who has stored service request information in a first 
format for use by the first computerized system to readily make the stored service 
request information available for use in a second computerized system that utilizes 
a second format in a cost-efficient and time-efficient manner, 
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[0025] FIG. 1A is a network diagram showing aspects of a typical hardware 

environment in which the facility operates. FIG. 1A shows a source system 110, a 
target system 130, an integration server 120 and a network 150. Source system 
1 1 0 stores service request information in a source format. There may be more than 
one source system. Target system 130 stores service request information in a 
target format. Target system 130 is described in greater detail herein, with 
reference to FIG. 1 B. 

[0026] The facility (not shown) converts some or all service request information that 

is in the source format into the target format by using an intermediate format of the 
service request information. In certain embodiments, such conversions are 
performed with the aid of one or more other computer systems, such as integration 
server system 120, Components of the facility may reside on and/or execute on any 
combination of these computer systems, and intermediate results from the 
conversion may similarly reside on any combination of these computer systems. 

[0027] The computer systems shown in FIG. 1A are connected via network 150, 

which may use a variety of different networking technologies, including wired, 
guided or line-of-sight optical, and radio frequency networking. In some 
embodiments, the network includes the public switched telephone network. 
Network connections established via the network may be fully-persistent, session- 
based, or intermittent, such as packet-based. While the facility typically operates in 
an environment such as is shown in FIG. 1A and described above, those skilled in 
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the art will appreciate the facility may also operate in a wide variety of other 
environments. 

[0028] FIG. 1B is a block diagram showing some of the components typically 

incorporated in at least some of the computer systems and other devices on which 
the facility executes, including some or all of the server and client computer systems 
shown in FIG. 1A. These computer systems and devices 100 may include one or 
more central processing units ("CPUs") 101 for executing computer programs; a 
computer memory 102 for storing programs and data - including data structures - 
while they are being used; a persistent storage device 103, such as a hard drive, for 
persistently storing programs and data; a computer-readable media drive 104, such 
as a CD-ROM drive, for reading programs and data stored on a computer-readable 
medium; and a network connection 105 for connecting the computer system to other 
computer systems, such as via the Internet, to exchange programs and/or data - 
including data structures. While computer systems configured as described above 
are typically used to support the operation of the facility, those skilled in the art will 
appreciate that the facility may be implemented using devices of various types and 
configurations, and having various components. 

[0029] It will be understood by those skilled in the art that the facility may transform 

service request information from a number of different source systems and from a 
number of different source software packages to a number of target systems and/or 
to a number of target software packages. 
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[0030] FIG. 2 is a high level flow diagram that shows some steps typically performed 

by the facility in order to convert service request information from the one or more 
source formats to the target format. At block 201, the facility extracts service 
request information from one or more source systems. At block 202, the facility 
converts the extracted information into an intermediate format. The intermediate 
format is described in greater detail herein, with reference to the common object 
data model. At block 203, the facility synchronizes the service request information 
from the source system with that of the target system by converting the service 
request information in intermediate format into the target format. After block 203, 
the steps as shown in FIG. 2 conclude. 

[0031] The steps shown in FIG. 2 may be repeated periodically, either to convert 

service request information that is changed in the source system since the last 
conversion, and/or to convert one or more particularly selected service request 
information. The facility may perform conversions from various source systems on 
which is executing various source software packages, and/or convert service 
request information to various target systems executing different target software 
packages. 

[0032] Efficiency of the service request capture and resolution may be measured 

with the following indicators: 1) number of service requests (by area, by customer, 
by severity, by source, etc.), 2) open service requests by time to resolve, by owner, 
by account, by age, etc., 3) number of closed service requests by time to resolve, by 
account, by area, by time period (month, week, day), etc. 
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[0033] FIG. 3A illustrates some a process flow for fulfilling a service request. At 

block 302, the customer reports a service issue to a customer service 
representative over the phone. The customer service representative identifies the 
customer and inquires if the call is regarding a new or existing issue, a customer 
service representative investigates a service request in response to a customer 
calling into the call center. If the customer is new, then a new contact is created for 
the customer before proceeding with the call. 

[0034] At block 304, the customer service representative issues queries to see if 

there are any existing open service requests for this customer. If the service issue 
is related to an existing service request then the customer service representative 
provides status to the customer and updates the service request with any new 
information provided by the customer. If the service issue is not related to any 
service request, then a new service request is created and all details are entered for 
this new service request. 

[0035] At block 306, the customer service representative verifies if the customer is 

entitled to receive the service associated with the service request. If the customer 
is not entitled to receive service, then the agent informs the customer about the 
same and transfers the call to a sales order agent to order a service agreement. 

[0036] At block 308, if the customer is entitled, then the customer service 

representative either takes ownership of the service request or assigns the service 
request to the appropriate person who can work on the service request. 
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[0037] At block 310, the customer service representative researches the service 

request and attempts to resolve the service request. At block 312, the customer 
service representative determines whether the customer is satisfied with the 
resolution of the service request. If the customer is not satisfied with the solution, or 
if the issue is not resolved within the commit time, then at block 314, the customer 
service representative attempts to escalate the service request by contacting the 
appropriate departments. If it is determined that the customer is satisfied, then at 
block 316, the customer service representative determines whether the resolution of 
the service request requires delivery of parts to the customer. If it is determined 
that parts are to be delivered, then at block 318, the customer service 
representative creates an order for the needed parts. Otherwise, if parts are not 
needed then at block 320, the service request is completed. 

[0038] FIG. 3B illustrates a process flow for an online self-service to obtain service 

requests. An online self-service business process enables customers and partners 
to create, update, track, and sometimes resolve their service requests online. At 
block 350, the customer logs into the self-service web site. At block 352, the 
customer either submits a new service request or updates an existing service 
request. 

[0039] At block 354, for an existing service request the customer queries for the 

service request, checks the status, and updates the service request with new 
information. At block 356, the updated information is sent to the MAIS to update the 



EV 099152865 US 

Attorney Docket: 38481 -8044.US01 



n 



corresponding service request. 

[0040] At block 358, for a new service request the customer creates a service 

request and fills in the details. At block 360, the new service request information is 
sent to the MAIS to create the service request. 

[0041] FIG. 4 illustrates an integration business process (IBP) for Synchronizing 

service request information between the source and target systems. At block 402, 
when a customer calls about a new service issue, the customer service 
representative captures the details of the service issue by creating a new service 
request. At block 404, this service request information is used to create a service 
request object that is referred to by both the source and target systems using the 
synchronization service request process. During the course of resolution of a 
service request, the service request information undergoes several modifications 
including addition of new activities, changes to status, owners, commit time, area, 
sub-area, addition of solutions/resolution documents, etc. At block 406, the 
synchronization service request process synchronizes the target system with the 
latest updated information from the source system (MAIS) and vice versa by using 
the service request object. 

[0042] The primary variables of a service request object are: 1 ) contact, 2) account, 

3) asset or product. When the service request is created, the service request is 
linked to one or more of the above primary variables. Additionally, variables such 
as severity, area, sub-area, summary, description, etc., may be passed. If the 
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service request already exists, then the IBP updates all of the service request 
variables/fields that changed since the last update or creation of the service 
request. Table 1 summarizes some of aspects associated with the service request 
object and synchronization service request process. 

[0043] TABLE 1 



Type^ 


Send 


Mode 


Asynchronous 


Sender 
Application 


MAIS applications, Micromuse, Remedy 

i 


Receiver 
Application 


Micromuse, Remedy, MAIS applications 


VBC or Data 
Replication 


Data Replication 


Primary Actor 


Customer Service Representative, Automatic events 
(Micromuse) ! 


Supporting 

Actors 


Service manager, external (target) applications 


Precondition 


All Contact, Account, Asset, and Product information that 
exist in MAIS should be synchronized with external (target) systems 
and Vice Versa, 


Minimal 
Guarantees 


MAIS to external (target) system: A Service request is created 
in the external system even if Account and Contact details cannot be 
found. If the service request already exists, then at least the key 

fields/records such as commit time, Area, Sub-area. Owner, Status, 



EV 0991 52865 US 

Attorney Docket: 38481 -8044.US01 



13 

BEST AVAIUBLE COPY 







activities within a service request, are updated. 

External (target) system to MAIS: A Service request is 
created in MAIS even if Account and Contact details cannot be 
found. If the service request already exists, then at least the key ^ 
fields/records such as commit time, Area, Sub-area, Owner, Status, | 
activities within a service request, are updated. 


Success 
Guarantees 




MAIS to external (target) system: A Service request is 
created/updated in the external system with all details such as 
account, contact, activities, etc., populated or updated. 

External system (target) to MAIS: A Service request is 
created/updated in MAIS with all details such as account, contact, 
activities, etc., populated or updated. 


Trigger 




Information should be sent out after a record is saved in the 
database 


Condition 




Area = "Network" if the target application is Micromuse. This 
should be configurable by the MAIS administrator. No conditions if 
Remedy is the target application. 


Post Step 




None 


MAIS BO 




Service Requests 


Package Size 


One Service Request and all the relevant details 


Master 
Dependencies 


Data 


Account, Contact, Products, Activities, Assets, Solutions 


Remote 
requirement 


data 


Service Requests should be set in mode "To be submitted" 
which should happen when users connects to the network 


Send 




List of Service Requests 
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Account Info i 




Contact Info 




service request Information (Area, Sub-area, Status, etc.) 




Asset Information 




Product Info 




Activities 




Type, Description, owner, etc. 




Audit Trail 




Info on all changes 


Receive 


None. 


Comments 





[00104] Once an service request is created or updated and saved in MAIS, the same 

information is sent to the external (target) system to create or update the same 
service request. With respect to the process flow from the external (target) system 
to MAIS, once a trouble ticket or service request is created or updated in the 
external (target) system or an event is triggered, information is sent to MAIS to 
create or update the service request. 

[00105] The Service Request Common Object includes the following information: 

• Service request number: System generated alpha-numeric code that 
identifies a service request uniquely. 
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• Account Name: Name of the account that the service request belongs 
to. 

• Site: Location of the account. 

• Summary: Brief description of reasons for logging a service request. 

• Description: Detailed description or explanation of the customer 
problems, issues, etc., which requires assistance. 

• Contact last name: Last name of the contact that logged the service 
request. 

• Contact first name: First name of the contact that logged the service 
request. 

• Status: Indicates the current status of the service request (Open, 
Closed, Pending, etc.). 

• Sub-status: Indicates the current sub-status of the service request 
based on the status selected. For example, potential sub-status 
values could be "Waiting for info", "More info needed", etc., for status 
= "Open". 

• Source: Indicates the channel (Phone, Web, Email, etc.) through 
which the service request was logged. 

• Area: Identifies the category (Hardware, Software, Network support, 
etc.) that the service request belongs to, 

• Sub-area: Identifies the sub-category within a category. 

• Priority: Customer's rating or ranking (Very high, High, Medium, etc.) 
that identifies the degree of customer's importance in resolving the 
service request. 

• Severity: Customer service center's ranking of the service request 
based on its own assessment. 
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• Owner: Employee ID of the person that is responsible for resolving the 
service request. 

• Time Opened: System time stamp when the service request was 
opened. 

• Time Closed: System time stamp when the service request was 
closed. 

• Time Committed: Indicates a point in time before which the customer 
should be responded to in resolving the service request. 

• Product: Indicates the product that is associated with the service 
request. 

• Part number: Manufacturer's code for identifying the product 
associated with the service request. 

• Asset number: Internal company code that uniquely identifies the 
product associated with the service request. 

• Profile: List of external products that could have potential interactions 
with the product identified above. 

[00106] Thus, the service request common object provides a unique, flexible, 

common data structure to represent various types of service requests for most 
industries. The service requests can be assigned to any organization, person or 
business unit. The service request common object also carries information about 
Parent Area, Sub Area, Product & environment data, Asset Number and 
Status/Priority codes. List of all activities performed (internal and published ) can 
also be transferred using the service request common object. 

[00107] The service request can be associated with various Contacts, Owners, 
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Organization. The Service request can also be associated with either Product or 
Installed Product. Also, environment information can be communicated using 
External Product and or External Installed product. 

[00108] FIG. 5 to FIG. 17 are data structure diagrams of the service request common 

object model. Such a service request common object model illustrates sample 
intermediate data structure that can contain information to be synchronized between 
the source and target systems. 

[00109] FIG. 5 is a block diagram that illustrates the components of a service request 

object as described herein. In FIG. 5, the service request common object includes 
a list of service request element 502, which in turn includes any number of service 
request components 504. The service request common object has a basic Type 
called ServiceRequestType as shown in the following figure. ServiceRequestType 
contains components of service request common object such as: 

Common Id 506; 

Base Data 508; 

Related parent Area 510; 

Related Root area 512; 

Related Contract 514; 

List of Related Contacts 516; 

List of Related Account (Customer) 518; 

List of Related Owner 520; 

Status Data 522; 
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Related Product (both Internal and External) 524; 
Related Installed Product (Customer Asset) 526; 
Related Business Unit 528; 
List of Related Activity 530; and 
Service request custom data 532. 

[00110] In FIG. 6, the illustrated intermediate data structure 600 is of type service 

request base data. Base data 602 may include the following components: 

• Abstract 604 (summary of requested service); 

• Channel source code 606 (e.g. phone, web, email, fax, etc.); 

• Closed Date 608 (date when service request is closed); 

• Commit time 610 (time before which to respond to the customer for resolving 
the service request); 

• Description 612 (detailed deschption or explanation of the customer 
problems, issues, etc., which require assistance); 

• Number 614 (service request number); and 

• Reported date 616. 

[00111] In FIG. 7, the illustrated intermediate data structure 700 is of type service 

request related parent area. Service request related parent area 702 includes a 
parent area component 704, which in turn may include the following components: 

• ID 706 (common ID of the functional area); 

• Base data 708 that can include a functional area name 714; 
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• List of related sub-areas 710 that can include any number of related sub- 
areas 716; and 

• Functional area custom data 712. 

[00112] In FIG. 8, the illustrated intermediate data structure 800 is of type service 

request related root area. Service request related root area 802 includes an ID 
component 804, which is the common ID of the functional area of the service 
request. 

[00113] In FIG. 9, the illustrated intermediate data structure 900 is of type service 

request related contracts. The related contract component 902 may include an ID 
904, a related contract base data 906, and a related contract custom data 908. The 
related contract base data 906 may include the following components: 

• Description 91 0 of the related contract; 

• Effective-to date 912 (up to what date is the contract effective); 

• ' Type code 914 (e.g., field services, service, etc.); 

• Number 916 ( contract number); 

• Effective-from date 918 (from what date is the contract effective); 

• Response code 920 (such as support codes, e.g., 24X7, service, e.g., 24X5 
service) and 

• Response time 922. 
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[00114] In FIG. 10, the illustrated intermediate data structure 1000 is of type service 

request list of related contact. The list of related contact component 1002 may 
include any number of related contacts 1004. Each related contact may include the 
following components: 

• ID 1 006 (common ID of a party); 

• Communication data 1008 (communication data for a party); 

• Data cleansing data 1010 (i.e., data that is related to data cleansing); 

• List of address 1 01 2 (address of a party); 

• List of relationship 1014 (relationships that a party can have with other 
entities); 

• List of alternate ID 1016; 

• List of License data 1 01 8; 

• Custom party data 1 020; 

• Person base data 1 022; . 

• Privacy data 1 024; and 

• Custom data 1 026 for the related contact. 

[00115] In FIG. 11, the illustrated intermediate data structure 1100 is of type service 

request list of related account. The list of related account component 1102 may 
include a related account component 1104, which in turn may include the following 
components: 

• ID 1 106 (common ID of a party); 
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• Communication data 1 1 08 (communication data for a party); 

• Data cleansing data 1110 (i.e., data that is related to data cleansing); 

• List of address 1112 (address of a party); 

• List of relationship 1114 (relationships that a party can have with other 
entities); 

• List of alternate ID 1116; 

• List of License data 1118; 

• Custom party data 1 1 20; 

• Base data 1122; and 

• Custom data 1 124; and 

[00116] In FIG. 12, the illustrated intermediate data structure 1200 is of type service 

request list of related owner. The list of related owner component 1202 may include 
any number of related owners 1204 (assignees of the service request). Each 
related owner may include the following components: 

• ID 1206 (common ID of a party); 

• Communication data 1208 (communication data for a party); 

• Data cleansing data 1210 (i.e., data that is related to data cleansing); 

• List of address 1212 (address of a party); 

• List of relationship 1214 (relationships that a party can have with other 
entities); 

• List of alternate ID 1216; 
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• List of License data 1218; 

• Custom party data 1 220; 

• Person base data 1222; 

• Privacy data 1 224; and 

• Custom data 1 226 for the related owner. 

[00117] In FIG. 13, the illustrated intermediate data structure 1300 is of type service 

request status data. The status data component 1302 may include the following 
components: 

• Priority code 1 304; 

• Severity code 1306 

• Status code 1308; and 

• Sub-status code 1 31 0. 

[00118] In FIG. 14, the illustrated intermediate data structure 1400 is of type service 

request related product. The related product component 1402 may include the 
following components: 

• ID 1404 (product ID); 

• Base data 1406 (product base data); 

• Sales data 1408 (product sales data); 

• Configuration data 1410; 

• Related product line 1412; 

• List of price type 1414 (collection of valid price types for this product); 
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• List of related inventory location 1416 (collection of valid inventory locations , 
e.g. warehouses, plants, that stock this product); 

• List of related product 1418; 

• List of related business unit 1420 (sales organizations that are authorized to 
sell this product); and 

• Custom data 1422 ( product custom data reserved for use by the customer). 

[00119] In FIG. 15, the illustrated intermediate data structure 1500 is of type service 
request related installed product. The related installed product component 1502 
may include the following components: 

• ID 1503 (common ID of an installed product); 

• Base data 1504; 

• Related parent installed Product 1506; 

• Pricing data 1508; 

• Related product 1 51 0; 

• List of related party 1 512 (account and owner of the installed product); 

• List of related order 1 51 4; 

• Related inventory location 1516; 

• Related business unit 1518; 

• List of attribute 1520; 

• Custom data 1522; and 
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• List of related installed product 1524 (list of related external Installed 
products associated with the installed product on the service request). 

[00120] Further, the list of related installed product may include any number of a 

related external products 1526. Each related external product 1526 may include the 
following components: 

• ID 1528 (product ID); 

• Base data 1 530 (product base data); 

• Sales data 1532 (product sales data); 

• Configuration data 1534; 

• Related product line 1536; 

• List of price type 1 538 (collection of valid price types for this product); 

• List of related inventory location 1 540 (collection of valid inventory locations , 
e.g. warehouses, plants, that stock this product); 

• List of related product 1 542; 

• List of related business unit 1 544 (sales organizations that are authorized to 
sell this product); and 

• Custom data 1 546 ( product custom data reserved for use by the customer). 

[00121] In FIG. 16, the illustrated intermediate data structure 1600 is of type service 

request related business unit. Service request related business unit 1602 includes 
an ID component 1604. 
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[00122] In FIG. 17, the illustrated intermediate data structure 1700 is of type service 

request list of related activity. The list of related activity component 1702 may 
include any number of related activities 1704. Each related activity component may 
include the following components: 

• Access code 1706 (e.g., private, audience, internal, etc.); 

• Comment 1708 (additional comments on action taken); 

• Duration 1710 (e.g., count, day, hour, etc.); 

• End date 1712; 

• Number 1714 (activity number); 

• Reason code 1716 (e.g., quality, defect, scheduled maintenance, un- 
scheduled maintenance, etc.); 

Start date 1718; 

• Task description 1 720 (description of action taken); 

• Type code 1722 (category of work, e.g., meeting, admin, etc.); and 

• Related owner 1 705. 

[00123] It will be appreciated by those skilled in the art that the above-described 

facility may be straightforwardly adapted or extended in various ways. For example, 
the facility may be used to transform various other kinds of service request 
information, and may be used to transform service request information between a 
variety of other formats. 

[00124] In the foregoing specification, embodiments of the invention have been 

described with reference to numerous specific details that may vary from 
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implementation to implementation. Thus, the sole and exclusive indicator of what is 
the invention, and is intended by the applicants to be the invention, is the set of 
claims that issue from this application, in the specific form in which such claims 
issue, including any subsequent correction. Any express definitions set forth herein 
for terms contained in such claims shall govern the meaning of such terms as used 
in the claims. Hence, no limitation, element, property, feature, advantage or 
attribute that is not expressly recited in a claim should limit the scope of such claim 
in any way. The specification and drawings are, accordingly, to be regarded in an 
illustrative rather than a restrictive sense. 
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